Add channel-transport transport OpenFOAM#551
Conversation
MakisH
left a comment
MakisH
left a comment
There was a problem hiding this comment.
Besides the fact that solver and config are in the same directory, it looks good overall. I have not yet tried to run it.
|
@fsimonis this seems to be close to merging. Does this need more work from your side, or just a new review iteration? edit: Actually, no. There is still a blocking modeling issue. |
|
Just finished a co-working session with @fsimonis. I pushed some new commits, which make the custom solver work with dynamic meshes and adjusts the case to apply dynamic mesh refinement with The settings are in Run with: The next step would be to further understand and adjust the mesh refinement settings. The coupled case currently fails, but this is expected since the adapter does not yet support remeshing (precice/openfoam-adapter#382). I can start an implementation of that. The accumulation of divSchemes
{
default none;
- div(phi,T) Gauss linearUpwind grad(T);
+ div(phi,T) Gauss linear grad(T);
}However, the numerics and the boundary conditions are the same as in the pitzDaily case, so this might be unrelated. I would look next if the changes from the standard Some URLs for reference: |
|
I got the non-AMR version running. I moved the AMR specific changes to #689 and will revert this PR to the non-AMR version. |
fsimonis
force-pushed
the
add-channel-transport-openfoam
branch
from
b1f4d6a to
44e2384
Compare
|
@MakisH I think I implemented all suggestions. Could you review again? |
MakisH
left a comment
MakisH
left a comment
There was a problem hiding this comment.
I applied a few more changes directly, and in terms of usability and integration to the rest of the tutorials, the case is ready. It still needs reference results for the system tests (I can add them).
I still have doubts about the outlet conditions and the space integration of T. But I am also still confused.
There was a problem hiding this comment.
I see the trick with the grading, it is already much better, but I am not yet sure that the case is correctly configured. The accumulation at the outlet is gone, but if I just change the mesh (I apply the same blockMeshDict from fluid-openfoam), I still see some accumulation at the outlet and an unphysical jump on the second-last layer:
channel-transport-openfoam.mp4
While I could accept that the origin of the issue is related to the mesh, I would like to better understand it.
Nutils
The combination fluid-openfoam/transport-nutils does not show this issue (solution available on mesh nodes only, Paraview interpolates):
transport-nutils.mp4
Fine grid
Even the fine grid case still shows some temporary accumulation near the center of the outlet when T first reaches the outlet:
channel-transport-openfoam-fine.mp4
If I restrict the value range to 0-0.2, some cells near the corner also look a bit strange, as the values at the last layer of cells are getting smaller than the values in the layer before:
channel-transport-openfoam-fine-range.mp4
Monolithic
To check the monolithic case, I removed the function object from the controlDict, I applied a similar initial condition as in the fluid-openfoam in U: internalField uniform (10 0 0);, and I used the same blockMeshDict as in the fluid-openfoam.
I observe the same "jump" before the obstacle (the accumulation is expected, since the flow field is constant and fully horizontal), but no issue with the outlet:
monolithic-DynamicScalarTransportFoam.mp4
Same with the standard scalarTransportFoam:
monolithic-ScalarTransportFoam.mp4
Conclusions
From this, I converge to:
- The issue at the outlet must be related to the combination of the volume coupling and the update of the outlet boundary, since it does not appear in the monolithic cases. But the issue is observed on the
T, not on theU, which is the one being read. I am confused. - The integration scheme of
Tcould still be improved, as the monolithic simulation shows discontinuities.
2 participants
This PR adds an OpenFOAM variant of the transport participant of the channel-transport tutorial.
The case uses a modified version of the scalarTransportFoam application. Main difference is that we assume$\phi$ every timestep.
Uto change every timestep. Therefore we need to recompute@MakisH Can you give this PR a thorough review to make it as easy to use as possible?
Result:
Screencast_20251210_145936.webm
Checklist:
changelog-entries/<PRnumber>.md.edit: updated to the working state